💡 今日學習目標：理解為什麼傳統「功能正常」的軟體開發思維在資安面前遠遠不夠，並建立「軟體品質即資訊安全」的核心防守視野。

🤖 關於 AI 協作：這個系列的研究彙整、圖表繪製與部分文字草稿，使用了 Anthropic Claude 協助，但每個案例的查證、程式碼的實際驗證與最終文字把關都由筆者親自完成，內容正確性由筆者負責。

📌 前言：在網際網路的「槍林彈雨」中，你的系統還安全嗎？

歡迎來到 2026 iThome 鐵人賽！接下來的 30 天，我們將一起走過一段從「資安新手」到「能夠為系統建立防守線」的實戰旅程。

不知道你有沒有過這樣的經驗？
身為一名開發人員，我們花費了無數個夜晚，終於把功能寫完、單元測試 Pass、效能調到極致，順利將產品部署上線。然而，上線不到幾天，伺服器的 Log 開始出現異常請求，甚至接到通知：「我們的資料庫好像洩漏了...」

在現代的網際網路環境中，任何一台聯網的伺服器，從上線的那一刻起，就已經置身於槍林彈雨之中。自動化掃描腳本與駭客工具每分每秒都在掃描公開 IP 與 Domain。

這不是危言聳聽。資安研究團隊 Palo Alto Unit 42 曾在北美、亞太與歐洲部署了 320 個蜜罐（Honeypot），也就是刻意暴露在網路上的誘餌伺服器，專門用來觀測攻擊者的真實行為。實測結果是：

• 80% 的蜜罐在 24 小時內就被攻陷，一週之內全數淪陷。
• 其中最驚人的一次，某個攻擊者在 30 秒內，就拿下了 80 個 Postgres 蜜罐中的 96%。

30 秒。比你泡一杯咖啡的時間還短。

📖 資料來源：Palo Alto Networks Unit 42 —《Observing Attacks Against Hundreds of Exposed Services in Public Clouds》(2021)

如果我們只追求「程式碼能跑、功能符合需求」，這就像建造了一座外表華麗的城堡，卻忘了安裝城門大鎖。

👋 先自我介紹：一個七成顧網路、三成顧資安的人

在正式開始之前，容筆者先交代一下自己是誰，以及為什麼會選擇用「品質」這個角度來談資安。

筆者在 IT 領域待了二十年以上，目前在企業內部服務，日常大約是七成時間管企業網路架構，三成時間處理資安。

換句話說，筆者不是那種專職做滲透測試、每天追 0-day 的資安專家，而是那個防火牆要顧、交換器要設、稽核來了要生文件、系統半夜出事要第一個爬起來的人。這些年下來，筆者導入過資安檢測工具與流程、處理過真實的資安事件、跑過稽核與合規，也在不少場合對外分享過這些經驗。

為什麼想寫這個系列？

站在這個位置上，這些年筆者看過太多開發團隊吃了悶虧。

不是因為他們技術不好，也不是因為不夠努力，而是在開發階段少想了那一步安全設計。等到系統要上線了、稽核進場了，甚至是事件已經發生了，才發現要付出的代價是整段架構打掉重來、上線時程無限延後，或是更難堪的資料外洩通報。

而那些悶虧，絕大多數在敲下第一行程式碼之前，其實都是可以避開的。

所以這 30 天，筆者想試著站在 「資安守門人」 的角度來寫：把守門時最常攔下來的問題、最常看見開發團隊踩進去的那些坑，一個一個攤開來講，提前告訴正要走進來的開發新手：這裡有洞，繞過去。

也正因為長期站在這個「什麼都得碰一點」的跨界位置上，筆者越來越確定一件事：資安並不是一門獨立的黑魔法，它跟製造業已經談了一百年的「品質」，本質上是同一件事。

這就是接下來 30 天，筆者想帶你走的那條路。

🔍 核心原理：功能好（Clean Code） ≠ 安全（Secure Code）

開發者常有一個迷思：「我的程式碼架構很漂亮，物件導向設計完善，邏輯也很清晰，這樣還不夠好嗎？」

答案是：不夠好。程式碼不只要好，更要安全。

❌ 傳統開發視角（以功能與商業邏輯為中心）

開發者習慣考慮「正常使用者（Happy Path）」的操作流程：

• 使用者輸入帳號密碼 ➔ 系統驗證 ➔ 登入成功。
• 使用者搜尋關鍵字 ➔ 系統查詢資料庫 ➔ 回傳結果。

🛡️ 資安防守視角（以邊界條件與潛在威脅為中心）

資安視角考慮的是「非預期的極端輸入與惡意意圖（Unhappy / Evil Path）」：

• 如果使用者輸入的不是帳號，而是一串 SQL 指令呢？
• 如果使用者修改了 Cookie 裡的 User ID，嘗試存取別人的薪資資料呢？
• 如果惡意程式大量發送封包，意圖耗盡系統資源呢？

邏輯對比範例：查詢使用者資料

// ❌ 傳統開發邏輯（只考慮功能正常）
Function GetUserProfile(userId):
    // 假設 userId 永遠是合法的數字，直接拼接到 SQL 查詢中
    SQL = "SELECT * FROM users WHERE id = " + userId
    Return Database.Execute(SQL)

⚠️ 隱患解析：當 userId 被帶入 1 OR 1=1 時，整張 users 資料表的資料將全數洩漏。

同一行程式碼，餵進不同的輸入，結果天差地遠，而程式本身完全沒有察覺任何異狀：

那麼，該怎麼修？

// ✅ 安全防守邏輯（加入邊界防禦與參數隔離）
Function GetUserProfile(userId):
    // 1. 強型別與格式驗證 (Validate Input)
    If NOT IsPositiveInteger(userId):
        Return Error("Invalid User ID")

    // 2. 參數化查詢 (Parameterized Query)，隔離指令與資料
    SQL = "SELECT * FROM users WHERE id = ?"
    Return Database.Execute(SQL, Parameters=[userId])

🛡️ 防守原理：無論輸入多麼離奇，參數化查詢會將輸入強行視為單純的「資料內容」，不會被資料庫當成「SQL 指令」執行。這就是跨語言共通的資安通則。

🛠️ 品質觀念看資安：這 30 天的完整路線圖

「資安看起來好複雜，工具又貴，小團隊或個人開發者哪有資源做資安？」

這正是本系列文章的核心起點！我們將借鏡軟體工程歷史上的 「品質觀念演進」 （從品質是「檢查」出來的，一路演進到「製造」、「設計」與「管理」），把資安拆解成四個層層遞進的防守階段。

這四階段，加上前面一段打底的觀念篇，就構成了這 30 天的五個階段：

其中標註 【動手做】 的篇章，都會附上可以直接照著操作的 Step-by-Step 步驟。

📝 關於本系列的程式碼範例：
觀念篇一律使用偽程式碼（Pseudocode），因為這些防守通則是跨語言共通的，不該被綁在某一種語法上；
動手做篇則會給你可以直接執行的真實程式碼（JavaScript / Python 等），因為那些單元你要親眼看到工具跳出告警，而偽程式碼餵給檢測工具是不會有任何反應的。

📦 想跟著動手做？先準備這些

這 30 天全程使用免費與開源工具，不需要任何付費授權。如果你打算跟著實作，建議先備妥：

• [ ] 一套順手的 IDE（VS Code、IntelliJ IDEA、Eclipse 或 Visual Studio 皆可），Day 08 開始用到
• [ ] Docker Desktop（Windows / macOS）或 Docker Engine（Linux），Day 09 開始用到
• [ ] 一個 GitHub 帳號，以及任何一個可以拿來測試的儲存庫，Day 28 會用到

當然，沒有這些環境也完全沒關係。觀念篇與原理解析的部分不需要任何安裝，純讀一樣能吸收。

⚡ 今日的 30 秒作業

既然這個系列主打「動手做」，第一天就不讓你只是讀完就走。

現在花 30 秒，打開 securityheaders.com，把你手上任何一個網站的網址貼進去按下 Scan。公司官網、你的個人部落格，或任何你正在維護的系統都可以。

它會回給你一個 A+ 到 F 的評分，以及一排綠色勾勾與紅色叉叉。

先把那個分數記下來，現在完全不用理解它在評什麼。 等我們走到 Day 19，你就會知道那幾個紅色叉叉分別代表什麼風險，以及該怎麼把它們一個一個變成綠色。

🎯 今日重點小結與防守心法

• 🔹 心法 1：程式碼不只要好，更要安全。功能正常只是起步，防範惡意輸入與邊界漏洞才是安全的關鍵。
• 🔹 心法 2：資安不是單一工具，而是品質習慣。不要等到事後被勒索或洩漏資料才來修補漏洞。
• 🔹 心法 3：沒預算也能做資安。這 30 天我們將全程使用免費與開源工具，帶你從零手把手建置防線。

💬 明日預告：【Day 02】資安該由誰來做？資安團隊、開發人員，還是「資訊水電工」？
明天我們將一起探討在組織與專案中，資安責任到底該如何劃分，開發新手又該站在什麼定位！